In distributed computer systems using the Distributed Component Object Model (DCOM) protocol, objects are distributed among various networked machines and are accessed via remote procedure calls (RPC). In DCOM, each computer that exports objects contains an object exporter providing client machines with information about objects residing on that machine. Some of the reference information that a client needs in order to access a remote object includes an interface identifier and an object identifier of the remote object, and the string bindings of the object. As is known, the string bindings identify a particular process on a particular machine such as a server process in which a remote object is implemented, along with the a network protocol to communicate with the machine.
One way in which DCOM obtains the reference information for a remote object is when a client application process asks for an object to be created, and, although the details are hidden from the client by DCOM, the object is created on a remote machine rather than locally. Reference information is returned by the remote machine as part of the activation process. The local client machine's DCOM routines unmarshal the returned reference information and store the information in tables of the client process and a local resolver process so that the requesting client process and other client processes can contact that remote object (via a proxy object). For efficiency reasons, the reference information does not directly contain the string bindings of the remote object, but instead contains the string bindings of the remote machine's resolver. If the string bindings for the remote object are not already known to the client machine, DCOM securely contacts the remote resolver via its local resolver to obtain the string bindings for that object so that the client process (via a proxy object) can access the remote object.
Another way in which DCOM obtains reference information for a remote object is when a remote process gives a client application an object reference. The client machine's DCOM likewise unmarshals this reference information and stores it in the client process and local resolver tables for use by client processes. Although this reference information is unsolicited, receiving reference information in this manner is desirable in that certain client processes may wish to access objects identified by such unsolicited references without having to undergo the expense of obtaining the object information. For example, at a certain time of day a database may send a reference to an object that a timed application uses shortly thereafter.
However, an unsolicited reference may contain bad information which can corrupt the tables maintained by the local resolver. More particularly, a client machine's resolver tables can be filled with information for a given object such that the wrong remote resolver may be contacted by the client machine's resolver during the attempt to obtain the remote object's string bindings. For example, a malicious machine can corrupt a table by sending the same object identifier (and similar reference information) as another object entry but with the string bindings of a different resolver. When a client machine attempts to use that object identifier, such as to look up the string bindings of the remote resolver for the purpose of obtaining the remote object's string bindings, two or more conflicting entries will exist with that object ID. The client machine may call the malicious machine's object exporter and thus get the string bindings to an unknown object. A centralized authority could maintain the table and thus eliminate conflicts, but will become overwhelmed with a large number of machines and thus is not a desirable solution for the DCOM framework.